home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-x400ops-mgtdomains-ops-05.txt
< prev
next >
Wrap
Text File
|
1993-03-26
|
27KB
|
860 lines
Operational Requirements for X.400 Management Domains
in the GO-MHS Community
March 26, 1993
Robert A. Hagens
C=US; ADMD= ; PRMD=INTERNET; DDA.RFC-822=hagens(a)ans.net;
hagens@ans.net
Alf Hansen
C=no; ADMD= ; PRMD=uninett; O=sintef; OU=delab; S=Hansen; G=Alf
Alf.Hansen@delab.sintef.no
$ Revision: 1.17 $
Status of this Memo
This document specifies a set of minimal operational
requirements that shall be implemented by all Management
Domains (MDs) in the Global Open MHS Community (GO-MHS).
This document defines the core operational requirements; in
some cases, technical detail is handled by reference to
other documents.
The GO-MHS Community is defined as all organizations which
meet the requirements described in this document.
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
When agreement is reached, it will be submitted to the RFC
editor as an informational document. Distribution of this
memo is unlimited. Please send comments to the authors or to
the discussion group:
INTERNET-DRAFT (OPS-1) [Page 1] Exp. Date: 05/10/93
ietf-osi-x400ops@cs.wisc.edu
C=us; ADMD= ; PRMD=xnren; O=UW-Madison; OU=cs; S=ietf-osi-x400ops
INTERNET-DRAFT (OPS-1) [Page 2] Exp. Date: 05/10/93
1. Introduction
There are several large, operational X.400 services
currently deployed. Many of the organizations in these ser-
vices are connected to the Internet. A number of other
Internet-connected organizations are beginning to operate
internal X.400 services (for example, U.S. government organ-
izations following U.S. GOSIP). The motivation for this
document is to foster a GO-MHS Community that has full
interoperability with the existing E-mail service based on
RFC-822.
The goal of this document is to unite regionally operated
X.400 services on the various continents into one GO-MHS
Community (as seen from an end-user's point of view). Exam-
ples of such regional services are the COSINE MHS Service in
Europe and the XNREN service in the U.S.
A successful GO-MHS Community is dependent on decisions at
both the national and international level. National X.400
service providers are responsible for the implementation of
the minimum requirements defined in this document. In addi-
tion to these minimum requirements, national requirements
may be defined by each national service provider.
This document refers to other documents based on ongoing
work, which will be published as Prototype and Informational
RFCs. These documents are [1], [4], [8] and [9] in the
reference list.
This document handles issues concerning X.400 1984 and X.400
1988 to 1984 downgrading. Issues concerning pure X.400 1988
are left for further study.
We are grateful to Allan Cargille and Lawrence Landweber for
their input and guidance on this paper. This paper is also a
product of discussions in the IETF X.400 Operations WG and
the RARE WG-MSG (former RARE WG1 (on MHS)).
1.1. Terminology
This document defines requirements, recommendations and con-
ventions. Throughout the document, the following defini-
tions apply: a requirement is specified with the word shall.
A recommendation is specified with the word should. A con-
vention is specified with the word might. Conventions are
intended to make life easier for RFC-822 systems that don't
follow the host requirements.
INTERNET-DRAFT (OPS-1) [Page 3] Exp. Date: 05/10/93
1.2. Profiles
Different communities have different profile requirements.
The following is a list of such profiles.
o U.S. GOSIP - unspecified version
o ENV - 41201
o UK GOSIP for X.400(88)
In the case when mail traffic is going from the RFC-822 mail
service to the GO-MHS Community, the automatic return of
contents when mail is non-delivered should be requested by
RFC 1327 gateways and should be supported at the MTA that
generates the non-delivery report. However, it should be
noted that this practice maximizes the cost associated with
delivery reports.
2. Architecture of the GO-MHS Community
In order to facilitate a coherent deployment of X.400 in the
GO-MHS Community it is necessary to define, in general
terms, the overall structure and organization of the X.400
service. This section is broken into several parts which
discuss management domains, lower layer connectivity issues,
and overall routing issues.
The GO-MHS Community will operate as a single MHS community,
as defined in [1].
2.1. Management Domains
The X.400 model supports connectivity between communities
with different service requirements; the architectural vehi-
cle for this is a Management Domain. Management domains are
needed when different administrations have different
specific requirements. Two types of management domains are
defined by the X.400 model: an Administration Management
Domain (ADMD) and a Private Management Domain (PRMD).
Throughout the world in various countries there are dif-
ferent organizational policies for MDs. All of these poli-
cies are legal according to the X.400 standard. Currently,
X.400 service providers in a country (inside or outside the
GO-MHS Community), are organized as:
a) One or several ADMDs.
b) One or several PRMDs and with no ADMDs present in the country.
c) One or several PRMDs connected to one or several ADMDs.
INTERNET-DRAFT (OPS-1) [Page 4] Exp. Date: 05/10/93
Or in combinations of a), b) and c). At this stage it is
not possible to say which model is the most effective.
Thus, the GO-MHS Community shall allow every model.
2.2. The RELAY-MTA
The X.400 message routing decision process takes as input
the destination O/R address and produces as output the name
(and perhaps connection information) of the MTA who will
take responsibility of delivering the message to the reci-
pient. The X.400 store and forward model permits a message
to pass through multiple MTAs. However, it is generally
accepted that the most efficient path for a message to take
is one where a direct connection is made from the originator
to the recipient's MTA.
Large scale deployment of X.400 in the GO-MHS Community will
require a well deployed directory infrastructure to support
routing. In the GO-MHS Community X.500 is considered to be
the best protocol for such an infrastructure. In this
environment, a routing decision can be made by searching the
directory with a destination O/R address in order to obtain
the name of the next hop MTA. This MTA may be a central
entry point into an MD, or it may be the destination MTA
within an MD.
Deployment of X.400 without a well deployed Directory
infrastructure, will require the use of static tables to
store routing information. These tables (keyed on O/R
addresses), will be used to map a destination O/R address to
a next hop MTA. In order to facilitate efficient routing,
one could build a table that contains information about
every MTA in every MD. However, this table would be enor-
mous and very dynamic, so this is not feasible in practice.
Therefore, it is necessary to use the concept of a RELAY-
MTA.
The purpose of a RELAY-MTA is to act as a default entry
point into an MD. The MTA that acts as a RELAY MTA for an MD
shall be capable of accepting responsibility for all mes-
sages that it receives that are destined for well-defined
recipients in that MD.
The use of a RELAY-MTA for routing is defined by [1].
RELAY-MTAss in the GO-MHS Community shall route according to
[1].
2.3. Lower Layer Stack Incompatibilities
A requirement for successful operation of the GO-MHS Commun-
ity is that all users can exchange messages. The GO-MHS
INTERNET-DRAFT (OPS-1) [Page 5] Exp. Date: 05/10/93
Community is not dependent on the traditional TCP/IP lower
layer protocol suite. A variety of lower layer suites are
used as carriers of X.400 messages.
For example, consider Figure 1.
-----------------------------------------------------
! !
! PRMD A !
! -------------------- !
! ! o x ! !
! ! ! !
! ! o w ! !
! ! z ! !
! -------------------- !
! PRMD B !
! ------------------ !
! ! o o ! !
! PRMD C ! o ! !
! ------------------ ! o z ! !
! ! o ! ! ! !
! ! o x ! ------------------ !
! ! o w ! !
! ! o ! !
! ------------------ !
! !
! Key: Each character the in !
! the boxes illustrates an MTA. !
! !
! x: TP0/RFC1006/TCP RELAY-MTA !
! w: TP4/CLNP RELAY-MTA !
! z: TP0/CONS/X.25 RELAY-MTA !
! o: MTA !
-----------------------------------------------------
Figure 1: A Deployment Scenario
PRMD A has three RELAY-MTAs which collectively provide sup-
port for the TP0/CONS/X.25, TP0/RFC1006, and TP4/CLNS
stacks[1] Thus, PRMD A is reachable via these stacks. How-
ever, since PRMD B only supports the TP0/CONS/X.25 stack, it
is not reachable from the TP0/RFC 1006 or the TP4/CLNS
stack. PRMD C supports TP0/RFC1006 and TP4/CLNS. Since PRMD
B and PRMD C do not share a common stack, how is a message
from PRMD C to reach a recipient in PRMD B?
[1] Note: it is acceptable for a single RELAY-MTA to sup-
port more than one stack. Three RELAY-MTAs are shown in
this figure for clarity.
INTERNET-DRAFT (OPS-1) [Page 6] Exp. Date: 05/10/93
One solution to this problem is to require that PRMD B
implement a stack in common with PRMD C. However this may
not be a politically acceptable answer to PRMD B.
Another solution is to implement a transport service bridge
(TSB) between TP0/RFC 1006 in PRMD C to TP0/CONS in PRMD B.
This will solve the problem for PRMD C and B. However, the
lack of coordinated deployment of TSB technology makes this
answer alone unacceptable on an international scale.
The solution to this problem is to define a coordinated
mechanism that allows PRMD B to advertise to the world that
it has made a bilateral agreement with PRMD A to support
reachability to PRMD B from the TP0/RFC 1006 stack.
This solution does not require that every MTA or MD directly
support all stacks. However, it is a requirement that if a
particular stack is not directly supported by an MD, the MD
will need to make bilateral agreements with other MD(s) in
order to assure that connectivity from that stack is avail-
able.
Thus, in the case of Figure 1, PRMD B can make a bilateral
agreement with PRMD A which provides for PRMD A to relay
messages which arrive on either the TP4/CLNP stack or the
TP0/RFC 1006 stack to PRMD B using the TP0/CONS stack.
The policies described in [1] define this general purpose
solution. It is a requirement that all MDs follow the rules
and policies defined by [1].
3. Description of GO-MHS Community Policies
A GO-MD is a Management Domain in the GO-MHS Community.
The policies described in this section constitute a minimum
set of common policies for GO-MDs. They are specified to
ensure interoperability between
- all GO-MDs.
- all GO-MDs and the RFC-822 mail service (SMTP).
- all GO-MDs and other X.400 service providers.
3.1. X.400 Address Registration
An O/R address is a descriptive name for a UA that has cer-
tain characteristics that help the Service Providers to
locate the UA. Every O/R address is an O/R name, but not
INTERNET-DRAFT (OPS-1) [Page 7] Exp. Date: 05/10/93
every O/R name is an O/R address. This is explained in [5],
chapter 3.1.
Uniqueness of X.400 addresses shall be used to ensure end-
user connectivity.
Mailboxes shall be addressed according to the description of
O/R names, Form 1, Variant 1 (see [5], chapter 3.3.2). The
attributes shall be regarded as a hierarchy of
Country name (C)
Administration domain name (ADMD)
[Private domain name] (PRMD)
[Organization name] (O)
[Organizational Unit Names] (OUs)
[Personal name] (PN)
[Domain-defined attributes] (DDAs)
Attributes enclosed in square brackets are optional. At
least one of PRMD, O, OU and PN names shall be present in an
O/R address.
In general a subordinate address element shall be unique
within the scope of its immediately superior element. An
exception is PRMD, see section 3.1.3. There shall exist
registration authorities for each level, or mechanisms shall
be available to ensure such uniqueness.
3.1.1. Country (C)
The values of the top level element, Country, shall be
defined by the set of two letter country codes, or numeric
country codes in ISO 3166.
3.1.2. Administration Management Domain (ADMD)
The values of the ADMD field are decided on a national
basis. Every national decision made within the GO-MHS com-
munity shall be supported by a GO-MD.
3.1.3. Private Management Domain (PRMD)
The PRMD values should be unique within a country.
3.1.4. Organization (O)
Organization values shall be unique within the context of
the subscribed PRMD or ADMD if there is no PRMD. For clarif-
ication: The following situation is legal:
INTERNET-DRAFT (OPS-1) [Page 8] Exp. Date: 05/10/93
1) C=FI; ADMD=FUMAIL; O=FUNET.
2) C=FI; ADMD=FUMAIL; PRMD=NOKIA; O=FUNET.
In this case 1) and 2) are different addreses. (Note that 2)
at this point is a hypotethical address). O=FUNET is a sub-
scriber both at ADMD=FUMAIL, 1), and at PRMD=NOKIA, 2).
3.1.5. Organizational Units (OUs)
If used, a unique hierarchy of OUs shall be implemented. The
top level OU is unique within the scope of the immediately
superior address element (i.e., Organization, PRMD or ADMD).
Use of multiple OUs may be confusing.
3.1.6. Given Name, Initials, Surname (G I S)
Each Organization can define its own Given-names, Initials,
and Surnames to be used within the Organization. In the
cases when Surnames are not unique within an O or OU, the
Given-name and/or Initial shall be used to identify the
Originator/Recipient. In the rare cases when more than one
user would have the same combination of G, I, S under the
same O and/or OUs, each organization is free to find a prac-
tical solution, and provide the users with unique O/R
addresses.
Either one of Given-name or Initials should be used, not
both. Periods shall not be used in Initials.
To avoid problems with the mapping of the X.400 addresses to
RFC-822 addresses, the following rules might be used. ADMD,
PRMD, O, and OU values should consist of characters drawn
from the alphabet (A-Z), digits (0-9), and minus. Blank or
Space characters should be avoided. No distinction is made
between upper and lower case. The last character shall not
be a minus sign or period. The first character should be
either a letter or a digit (see [6], [7]).
3.1.7. Domain Defined Attributes (DDAs)
The GO-MHS Community shall allow the use of domain defined
attributes. Note: Support for DDAs is mandatory in the func-
tional profiles, and all software must upgrade to support
DDAs. The following DDAs shall be supported by a GO-MD:
"RFC-822" - defined in [3].
The following DDAs should be supported by a GO-MD:
INTERNET-DRAFT (OPS-1) [Page 9] Exp. Date: 05/10/93
"COMMON" - defined in [2].
3.2. X.400 88 -> 84 Downgrading
The requirements in [2] should be implemented in GO-MDs
3.3. X.400 / RFC-822 address mapping
All GO-MHS Community end-users shall be reachable from all
end-users in the RFC-822 mail service in the Internet
(SMTP), and vice versa.
The address mapping issue is split into two parts:
1) Specification of RFC-822 addresses seen from the X.400 world.
2) Specification of X.400 addresses seen from the RFC-822 world.
The mapping of X.400 and RFC-822 addresses shall be per-
formed according to [3].
3.3.1. Specification of RFC-822 Addresses seen from the
X.400 World
Two scenarios are described:
A. The RFC-822 end-user belongs to an organization with no defined X.400
standard attribute address space.
B. The RFC-822 end-user belongs to an organization with a defined X.400
standard attribute address space.
Organizations belong to scenario B if their X.400 addresses
are registered according to the requirements in section 3.1.
3.3.1.1. An Organization with a defined X.400 Address
Space
An RFC-822 address for an RFC-822 mail user in such an
organization shall be in the same address space as a normal
X.400 address for X.400 users in the same organization.
RFC-822 addresses and X.400 addresses are thus sharing the
same address space. Example:
University of Wisconsin-Madison is registered under C=US;
ADMD=Internet; PRMD=XNREN; with O=UW-Madison and they are
using OU=cs to address end-users in the CS-department. The
RFC-822 address for RFC-822 mail users in the same depart-
ment is: user@cs.wisc.edu.
INTERNET-DRAFT (OPS-1) [Page 10] Exp. Date: 05/10/93
An X.400 user in the GO-MHS Community will address the RFC-
822 mail user at the CS-department with the X.400 address:
C=US; ADMD=Internet; PRMD=xnren; O=UW-Madison; OU=cs; S=user;
This is the same address space as is used for X.400 end-
users in the same department.
3.3.1.2. An Organization with no defined X.400 Address
Space
RFC-822 addresses shall be expressed using X.400 domain
defined attributes. The mechanism used to define the RFC-
822 recipient will vary on a per-country basis.
For example, in the U.S., a special PRMD named "Internet" is
defined to facilitate the specification of RFC-822
addresses. An X.400 user can address an RFC-822 recipient
in the U.S. by constructing an X.400 address such as:
C=us; ADMD=Internet; PRMD=Internet; DD.RFC-822=user(a)some.place.edu;
The first part of this address:
C=us; ADMD=Internet; PRMD=Internet;
denotes the U.S. portion of the Internet community and not a
specific "gateway". The 2nd part:
DD.RFC-822=user(a)some.place.edu
is the RFC-822 address of the RFC-822 mail user after sub-
stitution of non-printable characters according to [3]. The
RFC-822 address is placed in an X.400 Domain Defined Attri-
bute of type RFC-822 (DD.RFC-822).
Each country is free to choose its own method of defining
the RFC-822 community. For example in Italy, an X.400 user
would refer to an RFC-822 user as:
C=IT; ADMD=MASTER400; DD.RFC-822=user(a)some.place.it
In the UK, an X.400 user would refer to an RFC-822 user as:
C=GB; ADMD= ; PRMD=UK.AC; O=MHS-relay; DD.RFC-822=user(a)some.place.uk
INTERNET-DRAFT (OPS-1) [Page 11] Exp. Date: 05/10/93
3.3.2. Specification of X.400 Addresses seen from the RFC-
822 World
If an X.400 organization has a defined RFC-822 address
space, RFC-822 users will be able to address X.400 reci-
pients in RFC-822/Internet terms. This means that the
address of the X.400 user, seen from an RFC-822 user, will
generally be of the form:
Firstname.Lastname@some.place.edu
where the some.place.edu is a registered Internet domain.
This implies the necessity of maintaining and distributing
address mapping tables to all participating RFC-1327 gate-
ways. The mapping tables shall be globally consistent.
Effective mapping table coordination procedures are needed.
The procedures defined in [4] shall be followed.
If an organization does not have a defined RFC-822 address
space, an escape mapping (defined in [3]) shall be used. In
this case, the address of the X.400 user, seen from an RFC-
822 user, will be of the form:
"/G=Firstname/S=Lastname/O=org name/PRMD=foo/ADMD=bar/C=us/"@
some.gateway.edu
Note that [7] specifies that quoted left-hand side addresses
must be supported and that these addresses may be greater
than 80 characters long.
This escape mapping shall also be used for X.400 addresses
which do not map cleanly to RFC-822 addresses.
It is recommended that an organization with no defined RFC-
822 address space, should register RFC-822 domains at the
appropriate registration entity for such registrations. This
will minimize the number of addresses which must use the
escape mapping.
If the escape mapping is not used, RFC-822 users will not
see the difference between an Internet RFC-822 address and
an address in the GO-MHS Community. For example:
The X.400 address:
C=us; ADMD=ATTMail; PRMD=CDC; O=CPG; S=Lastname; G=Firstname;
will from an RFC-822 user look like:
INTERNET-DRAFT (OPS-1) [Page 12] Exp. Date: 05/10/93
Firstname.Lastname@cpg.cdc.com
3.4. Routing Policy
To facilitate routing in the GO-MHS Community before an
X.500 infrastructure is deployed, the following two tables,
an MTA table and a Domain table, are defined. These tables
are formally defined in [1]. The use of these tables is
necessary to solve the routing crisis that is present today.
However, this is a temporary solution that will eventually
be replaced by the use of X.500.
The MTA table will define the names of RELAY-MTAs and their
associated connection data including selector values, NSAP
addresses, supported protocol stacks, and supported X.400
protocol version(s).
Each entry in the Domain table consists of a sub-tree
hierarchy of an X.400 address, followed by a list of MTAs
which are willing to accept mail for the address or provide
a relay service for it. Each MTA name will be associated
with a priority value. Collectively, the list of MTA names
in the Domain table make the given address reachable from
all protocol stacks. In addition, the list of MTAs may pro-
vide redundant paths to the address, so in this case, the
priority value indicates the preferred path, or the pre-
ferred order in which alternative routes should be tried.
The MTA and Domain tables are coordinated by the group
specified in the Community document. The procedures for
table information gathering and distribution, are for
further study.
3.5. Minimum Statistics/Accounting
The following are not required for all MTAs. The information
is provided as guidelines for MTA managers, and is based on
work in [8]. This is helpful for observing service use and
evaluating service performance.
This section defines the data which should be kept by each
MTA. There are no constraints on the encoding used to store
the data (i.e., format).
For each message/report passing the MTA, the following
information should be collected.
The following fields should be collected.
Date
INTERNET-DRAFT (OPS-1) [Page 13] Exp. Date: 05/10/93
Time
Priority
Local MTA Name
Size
The following fields are conditionally collected.
From MTA Name (fm)
To MTA Name (tm)
Delta Time (dt)
Message-id (id)
At least one of 'fm' and 'tm' should be present. If one of
'fm' and 'tm' is not present, 'id' should be present. If
both 'fm' and 'tm' are present, then 'dt' indicates the
number of minutes that the message was delayed in the MTA.
If 'id' cannot be mapped locally because of log file for-
mats, 'id' is not present and every message creates two
lines: one with 'fm' empty and one with 'tm' empty. In this
case, 'date' and 'time' in the first line represent the date
and time the message entered the MTA. In the second line,
they represent the date and time the message left the MTA.
The following fields are optionally collected.
From Domain (fd)
To Domain (td)
For route tracing, 'fd' and 'td' are useful. They represent
X.400 OU's, O, PRMD, ADMD and C and may be supplied up to
any level of detail.
4. Community Document
For the GO-MHS community there will exist one single COMMUN-
ITY document containing basic information as defined in [1].
First the contact information for the central coordination
point can be found together with the addresses for the file
server where all the documents are stored. It also lists
network names and stacks to be used in the RELAY-MTA and
DOMAIN documents. The GO-MHS community must agree on its own
set of mandatory and optional networks and stacks.
INTERNET-DRAFT (OPS-1) [Page 14] Exp. Date: 05/10/93
References
[1] U. Eppenberger, Routing coordination for an X.400 MHS-
service within a multi protocol / multi network en-
vironment, IETF Internet Draft, "draft-ietf-x400ops-
mhs-service-05.txt".
[2] S.E. Hardcastle-Kille: X.400 1988 to 1984 downgrading,
RFC 1328, May 1992.
[3] S.E. Hardcastle-Kille: Mapping between X.400(1988) /
ISO 10021 and RFC 822, RFC 1327, May 1992.
[4] Urs Eppenberger, Jeroen Houttuin, Paul Klarenberg, Jim
Romaguera: Co-ordination Procedures for RFC 1327 Gate-
ways, (IETF Internet Draft).
[5] <ref. CCITT Red Book, X.400>
[6] K. Harrenstien, et al. DOD Internet Host Table Specifi-
cation. Request for Comments 952, October 1985.
[7] R. Braden. Requirements for Internet Hosts -- Applica-
tion and Support. Request for Comments 1123, October
1989.
[8] The COSINE MHS Project Team, "Requirements for A Final
Format Of Traffic Statistics"
[9] C. Allan Cargille, Postmaster Convention for X.400
Operations, IETF Internet Draft, "draft-ietf-x400ops-
postmaster-01.txt"
INTERNET-DRAFT (OPS-1) [Page 15] Exp. Date: 05/10/93